Sprint 2 and 3 Design Documentation

* Your team will need to update the project documentation throughout the semester. You will start your design documentation in the DesignDoc.md, which is given to you in your project starter repository (and you used for the Design documentation - team exercise) and carry necessary updates as project evolves.

Your design documentation should provide a narrative that describes the design for the reader in a top-down manner. The DesignDoc.md template shows the structure for the design document. The design documentation will describe the overall structure of the software including the web application interface. It will then detail the individual subsystems in the design. Your documentation should discuss your unit test code coverage and address areas of low coverage. You can decide whether to do this on a subsystem basis, or as a separate section at the end of the design document.

For the reader to understand your narrative, you must have appropriate visual support in the document. This visual support will be in the form of:

• Domain model for the domain of your application.
• Class diagram(s) and narrative for all Sprint 2 (and previous) required sections in the DesignDoc.md
• Images of the unit test code coverage.

* Be sure to check the corresponding Sprint rubric, understand the deliverables and get early clarification from your instructor of any other expectations (e.g. completed and up-to-date Acceptance testing, Trello, etc.)

Sprint 4 Design Documentation

Your Sprint 4 design documentation will be the final documentation for the project. This will be an expansion of the documentation that you submitted in Sprint 2.

In addition to updating all the material in your Sprint 2 design document, you should address:

• Class structure diagrams that are readable in the submitted PDF. To adequately show your system, you will need to present the class diagrams in pieces located near the discussion in the document.
• A single class diagram of the overall system will not be effective.
• Correct labeling of relationships with proper notation for the relationship type, multiplicities, and navigation information will be important.
• Include other details such as attributes and method signatures that you think are needed to support the level of detail in your discussion.
• Sequence diagrams of at least two significant features in your system.
  • Include these diagrams, and a narrative description of them, in an appropriate place in the document.
  • If the sequence exists mainly within one subsystem then the section describing that subsystem would be appropriate.
  • If the sequence cuts across multiple subsystems, you may have to have your discussion at a higher level in the document outline.
• Discuss the quality of your design along with recommending future refactoring and other design improvements based on your analysis and review of the design against the object-oriented design principles covered in class.
• Identify 3-4 areas within your code that have been flagged by the Static Code Analysis Tool (SonarQube) and provide your analysis and recommendations. Include any relevant screenshot(s) with each area.

Note: Before final submission, be sure to reference the feedback from the Cross-team Design Document Review activity.